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ABSTRACT 



For communication services, a metering and processing 
system for processing metered information incorporates 
configurable processing modules and a configuration man- 
ager. The system can by readily and flexibly configured, 
responsive to operator directions, to process metered infor- 
mation to meet the needs of data consumers, such as NSPs 
and ISPs. Each processing module performs a specific 
sub-part of a computation on the metered information, and 
the configuration manager generates a configuration file for 
specifying the order of operation, computation sub -part, and 
other operational parameters for the individual processing 
modules. 

27 Claims, 10 Drawing Sheets 
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PIPELINED METHOD AND APPARATUS 
FOR PROCESSING COMMUNICATION 
METERING DATA 

HELD OF THE INVENTION ^ 

The present invention relates to telecommunication, and 
more particularly to computer processing of metered infor- 
mation regarding communication services. 

BACKGROUND OF THE INVENTION 

Known communication billing systems meter usage of 
telephone services and prepare billing based traditionally on 
time and distance of telephone calls. While such billing 
systems met the needs of telephone companies for many 
years, the telecommunication market is experiencing funda- 
mental changes giving rise to a need for new billing systems, 
which are more flexible and robust. These changes are 
driven by worldwide deregulation, privatization, increased 
competition, and new communications technologies, such as 
the Internet, and the advent of Internet-Protocol (IP) net- 
works. 

With increased competition among aggressive new 
entrants and diversifying telephone service companies in the 
burgeoning telecommunication market, margins on voice 
and other services are under pressure. As a result, network 25 
service providers (NSPs) and downstream, independent ser- 
vice providers (ISPs) are looking at ways to differentiate 
themselves from their competition. One way is to offer value 
added services packages, often called "products", including, 
for example, an ever- changing variety of telephone calling 3Q 
plans. Other such value added services include video-on- 
demand, Web hosting, and streaming media. These value 
added services are not typically billed like traditional 
telephony, but rather pursuant to special or even customi/xd 
billing plans. Special pricing may apply depending on total 35 
or aggregate usage, calling "time of day" or "day of the 
week", or combinations of services purchased. Many value 
added services are packaged for particular market segments, 
such as residential, small business or enterprise, and carry 
different rates depending on segment. Some provide sub- 
scribers with a menu of telecommunication services from 
which to choose, often with a number of billing options for 
each. 

One problem that arises relates to integration of such new 
value added services into existing billing systems. 45 
Traditionally, NSPs used large mainframe computers and 
custom-designed billing software that typically required 
months for modification for integration of new value added 
services and their accompanying billing plans. Such modi- 
fications to existing billing systems represented a high 50 
overhead, in terms of cost and time, associated with rollout 
of new value added services. For example, when a major 
NSP introduced a new telephone plan for residential cus- 
tomers called "Friends and Family*^"", it enjoyed a nine 
month lead over its competitors who were delayed in 55 
introducing similar products by the time it took to modify 
their existing billing systems. Lengthy delay in "time lo 
market" can cost NSPs and ISVs significantly in revenue 
and market share. 

New service products arising from new technologies go 
introduce complications as well, because NSPs and ISVs 
frequently want such services to be bundled with traditional 
services as a unified package, or, at their option, billed as 
single or separate products. Traditional billing platforms do 
not usually provide such flexibility in billing. 55 

Moreover, NSPs and ISVs may wish to meter, monitor 
usage, and generate usage reports for a variety of reasons 
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Other than bill preparation. It may prove useful for NSPs and 
ISVs to meter services, even though they do not currently 
bill customers for such services, in order to determine 
whether they should start billing for such services in the 
future. For other services, NSP and ISVs may rely on 
usage-graduated billing plans to charge for excessive net- 
work use and thereby discourage potential network bottle- 
necks. Such billing schemes typically charge users only 
when usage crosses a preset threshold, and thus such ser- 
vices require metering for comparing actual usage against 
the threshold. 

To illustrate the complexity involved with billing, a 
universal messaging service may offer fax, voice, video, 
pager, and email capabilities. Most users would currently 
assume that everything except email should be metered and 
billed; email is usually regarded today as "free". 
Unfortunately, spamming is common practice and email 
files containing attachments are increasing in size. One can 
imagine an NSP creating a services billing plan that allows 
users to send, for example, 5000 emails and 100 MB of 
traffic per month for free as part of a messaging service, but 
then apply usage-based charges for anything above those 
levels. Data volume is a common reason for metering 
high-volume services. 

It would be desirable to provide NSPs and ISPs with 
flexible billing platforms that enable rapid deployment of 
new value added service offerings. Such platforms should 
enable rollout of new services, e.g., within weeks, and new 
releases, upgrades or updates several times a year without 
interrupting billing activity. Preferably, such platforms 
would reduce overhead associated with the rollout, and 
provide an "end-to-end" solution to billing for such new 
services. 

It would also be desirable to provide a system for enabling 
NSPs and ISPs to have real-time access to unified billing 
data based on customer usage of new value added services. 
This would enable NSPs and ISPs to track customer usage 
for purposes of business management, and implement 
appropriate changes to value added services as indicated by 
the usage data. 

SUMMARY OF THE INVENTION 

The invention resides in a metering and processing system 
for processing metered information, which incorporates 
configurable processing modules and a configuration man- 
ager. The system can by readily and flexibly configured, 
responsive to operator directions, to process metered infor- 
mation to meet the needs of data con.sumers, such as NSPs 
and ISPs. Each processing module performs a specific 
sub-part of a computation on the metered information, and 
the configuration manager generates a configuration file for 
specifying the order of operation, computation sub-part, and 
other operational parameters for the individual processing 
modules. 

The processing modules, referred to herein also as "plug- 
ins", can operate under the control of an execution manage- 
ment framework. The plug-ins can be viewed as plugging 
into and out of the framework, and as modular, reusable 
computational pieces or building blocks, which come 
together to perform the computation under the direction of 
the framework and pursuant to a configuration file. The 
plug-ins can be added, removed, and/or replaced for modi- 
fying the calculation performed by the system in generating 
output data. For use, a user or operator devices the 
computation, e.g., calculation formula, required for a par- 
ticular VAS, and uses the configuration manager's user 
interface to select and order the plug-ins to carry out that 
formula. 
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More specifically, the system can have a mechanism for FIG. 7 is a block diagram of the architecture of a 
converting the metered information into session data, a conventional computer system, 
processing unit for processing the session data, and a con- 
figuration manager. The processing unit performs calcula- DETAILED DESCRIPTION 
tions on the session data to generate processed session data, 5 . . Term noloev 
and includes an execution management framework, and a ^ ^ 

plurality of plug- ins for processing the session data as It may be useful to start the description of illustrative 

directed by the framework with each performing a sub-part embodiments of the invention by introducing certain termi- 

of the calculations. The configuration manager generates a nology. A network entity is a device that is connected to a 

configuration file reflecting user selections of configuration network. A session (also known as a transaction) represents 

parameters for plug-in execution. The configuration man- ^he use of a service by a client as a collection of properties 

ager can include a user interface for receiving the selections, (defined below). An application server is an entity that 

mcludmg, e.g., an order of operation and the calculation provides application services to clients, and is typically a 

function or sub-part for each plug-in in accordance with data ^^.^^^ ^ ^^^^^ ^^^^^ application service is a task that 

consumer requirements. Tlie session data can include prop- ^ performed by an application for a client. The task per- 

erty name/value pairs pertaming to a session, and the plug- ^J^^^ ^ for example, fax/voice calls, video 

ins can perform operations, including mathematical ^ , . . ' ■ j * . ■ «n- »» ^ u 

^ *^ ^ , . • . u* ■ ♦ streaming, web hosting, data storing. "Properties describes 

operations, on the property name/value pairs to obtain a set . f l- . V . j, c .1 

\ \ ^ the quantities that may be metered for a particular service, 
of processed session data. * ai *u»u 
^ , . , , • , 1 1 . A property is represented by a nameA^alue pair, where the 
The system can be implemented to include a multi-stage ^^^^ ^ human-readable identifier understood 
processing pipelme, each pipeline stage mcludmg multiple ^^^^^ ^^^^^^ ^ ^^^^ Examples of property names 
processing modules and an execution management include "by tes-sent" and "duration". A property thus would 
framework, and capable of multi-thrcading operation to represented, e.g., by the pair "bytes sent«1024" or 
cause the plug- ins to execute in series or in parallel to speed "durational 20" 
processing by the plug-ins while accommodating computa- 
tional dependencies. In some embodiments, the system can B) Metered Information Processing System 
also have a metering apparatus for collecting the metered Architecture 
user information, and a presentation manager for providing ^^^^^ illustrative architecture for metering 
processed session data to data consumers. processing system 100 that provides a scalable infra- 
Accordmgly. a system m accordance with the mvention ^j^^^j^^^^ ^^j^^^ ^^^^^ prevision, account for, authenticate, 
can provide a scalable infrastructure to meter, rate authorize, and bill for services, such as usage-based services, 
prov^ion. account for authorize, authenticate, mediate, and processing system 100 includes a number 
Ml for services, such as usage-based services. NSPs and ^^^^^ ^^^^ ^^.^ (^AS) devices 102 for metering 
ISPs can advantageously employ the system to meter communications services and thereby generating metered 
detailed usage information and assign charges for value data in a prescribed form; a metered data processing system 
added services. ITiey can also use the system for processing processing the metered data to generate useful 
other metered information regarding the services and their information regarding communication services usage; and a 
use, such as, for example, information tor authentication of ^^^^^^ ^^^^ consumers 106 (including, for example, 
users, for prepayment or for credit pre-auUionzation for ^gp^ j^p^^ ^^ ^^^ Essentially, the 
servicecharges.ThesystempermitsNSPsandISPstocreate j^,^ calculated from the metered data can include 
new rating schemes and cross-service plans by entering the determinations, tariff determinations, rating, and 
appropriate computatiowl parameters using the configura- ^^^^^^ ^ jj^^ ^^^^ consumers for a variety of 
tion manager s user interface, e.g., a graphical user interface ^^^^^^ ^^^^ ^^^^^^^ ^^^^^^ 

^ ^' The VAS devices 102 include, for example, an audio 
BRIEF DESCRIPTION OF THE DRAWINGS 45 conference bridge U6 for metering audio conferencing 

The above and further advantages of the invention may be services usage, a streaming media server 114 for metering 

better understood by referring to the following description in streaming media services usage, and other VAS servers 116, 

conjunction with the accompanying drawings in which: such as telephone services servers for metering telephone 

FIG. lA is a blockdiagram of a metering and processing ^^vi^e ^^age. The metered data regarding the use of a 
system in accordance with an embodiment of the invention; 50 particular VAS by a particular user constitutes what is 

FIG. IB is a block diagram illustrating an exemplary referred as a "session", and the particulars of the session are 

, . • r 4- . 1 ■ r „ 7- u- * p described in terms of a set of properties that have values, 

technique tor Keneratme metered iniormation oniects lor „ , . , , ,1 

^. • ,u • r r nir' ia Each session thus contains at least one name/value pair. I.e., 

processing in the pipeline of HG. I A; . , . . , 1 t - 

1-^^ • r I a name identifying a particular property and a value setting 

FIG. 2 is a block diagram providing an overview of the r *u * * t? 1^ « 

• r f Pir 1 A. 55 lonh a quantification of that property. For example, a Qme 

pipe ine o .a; ... stamp property can have a certain date and time value, e.g., 

BG. 3 is a block diagram showing the pipebne of FIG. lA u^^^ ^999^ 23:59". The VAS devices 102 are respon- 

as implemented on multiple computer systems; ^^^^ ^^^^-^^ sessions, generating the session objects, 

FIG. 4 IS a block diagram depicting the architecture of a adding properties and sub-sessions to the session objects, 

stage of the pipeline of FIG. lA; ^^^^ ^h^n VAS devices 102 completes processing of the 

FIG. 5 is a block fa portion of RG. lA involved in plug-in individual sessions, storing the session objects and trans- 
configuration and operation; mitting them (preferably in serialized form) to the process- 

FIG. 6A is a block diagram illustrating an exemplary ing system 104. For purposes hereof, the sessions are 

dependency graph; represented as session objects, for example, in extensible 

FIG, 6B is a block diagram of a plug-in, showing a 65 Markup Language ("XML") format. The concept of 

dependency tracking mechanism in accordance with an "objects" are well known to those familiar with object 

embodiment of the invention; and oriented programming. 
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XML is a standard, data structuring and formatting lan- 
guage intended, e.g., for use in IP network (e.g., Internet) 
applications. XML is compatible with and complementary 
to, Hypertext Markup Language (HTML), at least in its 
current version. It is a standard way of describing a class of 5 
data objects as stored in computer systems, called XML 
documents, and behavior of programs that process these 
objects. XML documents are made up of storage units called 
entities, which contain either text or binary data. Text is 
made up of characters, some of which form the character 
content of the documents, and some of which form markup. 
Markup encodes a description of the document, such as its 
storage layout and logical structure. An XML document 
includes a hierarchical set of markup elements, where most 
elements have a start tag, followed by content, followed by 
an end tag. Tags are enclosed in angle brackets ("<" and">") 
and indicate structure labels for markup elements, such as, 
for example, titles, identifiers, dates, lists, and links to other 
data. Depending on context, XML also refers to an 
in-memory object structure, which is compliant with the 
XML standard's semantics. A software module called an 
XML processor and executable on a computer system, is 
used to read XML documents and provide access to their 
content and structure. Many XML concepts are used herein, 
such as "documents", "elements", "tags", "attributes", 
"values", "content", "entities", "links", and "pointers". Fur- 
ther information regarding XML can be had with reference 
to Version 1.0 of the XML specification, available at 
<HTTP/www.w3.org/pub> on the Internet, and incorporated 
herein by reference. 

The processing system 104 can include a plurality of 
metering servers 120, a transaction processor pipeline 130, 
a memory 135, a presentation manager 140, and a configu- 
ration manager 150. llie metering servers 120, numbered 1 
through n, are each associated with a dilferent one of the 35 
VAS devices 102 for performing the following functions: 
receiving metered information in the form of session objects 
from the associated VAS device, persistently storing the 
session objects, and passing the session objects to the 
pipeline 130. 4q 

llie pipeline 130 processes the metered session through a 
sequence of steps or stages that transform the metered data 
contents of the session objects into the processed usage data, 
which are stored in memory 135. The processed usage data 
can include a subset of the metered properties of the metered 45 
data along with additional properties that are synthesized 
from the metered properties. The pipeline 130 can aggregate 
metered data from related or unrelated transactions. The 
aggregated data can then be incorporated in reports or in 
calculations based on aggregate usage of a product, such as, 50 
for example, monthly service plans, A special case of data 
aggregation is collecting data from child sessions and report- 
ing the aggregated data in a parent session. 

The presentation manager 140 receives the processed 
usage data directly from the pipeline 130 or via the memory 55 
135 and provides the processed usage data to the data 
consumers 110, preferably in a format specified by the 
individual subscribers. For example, the presentation man- 
ager 140 can serve as a reporting interface for enabling data 
consumers to view the usage data, e.g., service charges, in 60 
real-time. In an illustrated implementation, data consumers 
can use an Internet browser such as Microsoft Internet 
Explorer '^'^ or Netscape Navigator''" to access a logon page 
for the presentation server and, after logon, view displays of 
metered usage for the particular account. 65 

ITie communication metering system 100 also has a 
configuration manager 150 responsible for configuring the 
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metering servers 120, pipeline 130 and presentation man- 
ager 140; and a repository services manager 160 responsible 
for managing storage of sets of configuration information. 

Data consumers 106 can include service information 
subscribers, e.g., NSPs and ISPs. Each of the data consumers 
106 can use a user interface (UI) 162 to view the service 
information on request, store the service information in 
archival storage 164 for later use, or use the information, 
e.g., in a system 166 for billing, provisioning and providing 
customer support ("Operation System Support" or "OSS"). 

FIG. IB illustrates the operation of an exemplary one of 
the VAS devices 102 and the associated metering server 120 
with respect to the generating of session objects. ITie VAS 
device 120 has a metering module ("meter") 170 for meter- 
ing a particular VAS and thereby collecting usage data, and 
an object generation module 172 for generating objects from 
the usage data and providing the objects to the session server 
120. The meter 170 can be of conventional design, and 
specific to a particular VAS. The object generation module 
172 has a user interface 174, an object generator 176, and a 
transmission module 178, which can be, for example, all 
bundled as part of a software development kit (SDK) for use 
by metering application programmers. Additionally, the 
SDK can provide a standards-based mechanism for com- 
munication between the VAS devices and the metering 
servers. 

The user interface 174 can include, e.g., an application 
programming interface (API) for interfacing with, and there- 
fore reformatting data as required from, the metering module 
172. The object generator 176 generates session objects 
containing properties having values representing the usage 
data. The transmission module 178 can include a serializer 
182, an encoder 184, and a transmitter 186. ITie serializer 
182 serializes the objects to be transmitted into an object 
stream. The encoder 184 encodes the object stream, for 
example, for error detection purposes and/or authentication 
purposes. The transmitter 186 transmits the encoded object 
stream, e.g., embedded in a carrier wave, to the session 
server 120. TTie transmission may pass across a network 
boundary 180 separating a first network 182 containing the 
VAS device 102 from a second network 184 containing the 
session server 120. 

The session server 120 includes a receiver module 186, a 
persistent storage manager 188, a parser 190, an object 
factory 192, and a distribution module 194. The receiver 
module 186 includes a receiver 195 for receiving the 
encoded object stream, and a decoder 196 for decoding the 
encoded object steam back into an object stream. The 
persistent storage manager 188 is responsible for storing the 
object stream into a transaction log 198, which records the 
object steam in a suitable database. The parser 190 parses the 
object stream into discrete objects to extract the data content, 
including, for example, account and session identification 
information, and name/value pairs contained therein. 

A communication transaction can have a variety of infor- 
mation captured in the data content. For example, the data 
content can include a server host name (the name of a 
metering server); a server user name (a name to use when 
sending sessions to the metering server); the server pass- 
word (a password to use when sending sessions to the 
metering server); account ID (an account to which the 
session will be metered); a transaction description (a 
description of the transaction); amount (a monetary amount 
assigned to the transaction); and a unit of measure (a 
currency of the amount), among other content. 

For example, a communication transaction can have a 
time stamp of 4AM, account identification information (e.g., 
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version number, uid, and entity), session identification infor- machine availability; the illustrated implementation merely 

mation (e.g., commit, account identifier, and parent being exemplary. The pipeline controller 210 can be a 

identifier), and, e.g., two properties having name/value pairs computer-executed program stored and executed, for 

of duration/777 and namcpcrson/David. In that case, the example, on one of the machines 202, 204, 206 or a separate 

following object stream, expressed in XML format, could 5 machine (not shown). The stages 202, 204, 206 arc chained 

j.ggy]|. (i.e., connected) together via message queues 212, 214 

connected in the data stream between the adjacent stages for 

<session> , ^ ^ , , . passing session objects therebetween, including partially or 

<timestamp>4:00AM</timestamp ^^^^^^ processed objects. The queues 212, 214 enable 

<version>1.0</version> non-synchronous operation of the stages. Each of the stages 

<uid>x6s09uAkgKgCaDZDF29+w</uid> 10 ^^^^ 204, 206 coordinates the execution of a number of 

<entity>dsmith.abc.com</entity> processing modules ("plug-ins") 220, supported by an 

<b6gmsession> execution management framework 225. The plug-ins 220 

<dn>abc.com/x</dn> viewed as plugging into and out of the execution 

<commit>y</commit> management framework 225, depending on computational 

<accountid>x6s0956789</accountid> 15 ^^^^-f^^^^^^ 

<parentid>abc</parentid> Plug-ins 220 are modular, computer-executable objects 

P ^ each containing a process for performing a single function, 

J J /J e.g., a specific portion of a calculation on the value portion 

<dn>duration</dn> ' ^ ^ ^ , , . . . 

<value>777</value> 20 ^ property name/value pair. 1 ne remaining portions of the 

. calculations are performed by other plug-ins 220. The pro- 

</proper y> contained in a plug-in includes a sequence of execut- 

F able computer instructions organized in one or more callable 

^ T J J / ^ procedures or routines. Plug-ins 220 preferably have a 

<value>david</value> ^ ^ . • . r r • . 

. 25 system services interface for accessing system services 

< p p y> provided via the framework 225, e.g., to allow the plug-ins 

tu. ' 220 to read configuration data. The order of execution of 

. ' ' plug-ins 220 can be determined by a dependency graph or its 

</session> equivalence, as described below, and established by the 

The parser 190 would parse this object stream and extract pipeline controller 210 

the time stamp of 4AM the version number. Uid, entity, the 3 ^j,^^^ ^ per-machine view of the transaction 

commit, account identifier parent identifier, and the name/ processor pipeline 130, as implemented in three pipeline 

value pairs of duration/777 and nameperson^avid. machines 302, 304, 306. The machines 302, 304, 306 are 

•nie object factory 192 converts the object contents interconnected, for example, by a network 310, which is 
extracted by the parser into factory session objects, e.g ^^^^^ convenience at both 310A, 310B. Each machine 
reconstitutes the session objects from the object content of 3^2^ 3^4^ 3^5 ^^^^^^ ^ .^^^ component 312, 314, 316 
the stream. Tliese session objects can include not only the ^ ^^^^ ^22, 324, 326, respectively. The pipe- 
same objects as generated by the object generator 176 and 202, 204, 206 shown in FIG. 2 are each imple- 
descnbed above, but also other objects formed for particular ^^^j^^ ^ ^ respective one of the pipeline components 312, 
processing requirements. Such 'other pipehne objecu can 3^4 3^5 ^^^^ ^ -(,1^ „f executing one or more of the 
include aggregate objects, ,n which the contents of d.fterent , „^ ^^^^^^ j^^^ ^^^j^^ objects). Each pipeline 
session objects are aggregated^ .such as, for example, dura- , 312, 314, 316 passes session identifiers (SIDs) 
tion time aggregated from different session from the same ^-^ ^^^^ ^^^^^^^ 320 to the machine 302, 304, 306 that 
^^^i!^" , , ^^^^ , , . executes the successive pipeline stage (i.e., the next machine 

Tlie distribution inodule 194 forwards the session objects, 3^2, 304, 3O6) for identifying the session. The associated 

under the control of the configuration manager 150, to the ^^^^^^ ^^^^^ ^^I, 324, 326 passes session objects via the 

pipelme 130 for processing. The session objects processed in ^^^^^^^ 320 the session server 322, 324, 326 of the 

Jhe pipebne 130 will be sometimes referred to as simply successive pipeline stage 202. 204, 206 (i.e., to the next 

session objects . machine 302, 304, 306) to enable processing to be continued 

C) 'ITie Tran.saction Processor Pipeline 50 in that successive stage. 

A session server 440 is responsible for receiving session 
FIG. 2 shows an illustrative embodiment of the tr ansae- data, e.g., session objects, from a prior session server. In 
tion processor pipeline 130, which processes session data, addition, the session server 440 is responsible for maintain- 
preferably in session object form containing property name/ ing session storage 420. 

value pairs, to produce processed session or usage data. The 55 FIG. 4 shows an architectural view of a pipeline stage 
pipeline 130 passes the processed usage data to the presen- 400. The stage 400 includes an input queue 402 (e.g., a FIFO 
tation services manager 140 of FIG. 1 for presentation to buffer), a multithreading process space 404, and an output 
data consumers 106. queue 408 (e.g., a FIFO buffer). The process space 404 
The pipeline 130 is made up of a number of pipeline processes a number of plug-ins, numbered 1 through 8, 
stages 202, 204, 206 under the control of a pipeline con- 60 under the control of an execution management framework 
troUer 210, The pipeline stages can be implemented within 412, and pursuant to processing threads stored in a thread 
a single computer system ("machine"), but preferably are pool 414. A stage configuration module 416 receives con- 
implemented on multiple, coordinated machines, as shown figuration files 418 from the configuration manager 150, 
in FIG. 3 for increased speed and flexibility in operation. which define stage operations as well as operation of the 
llie exact number of stages and machines used in an 65 plug-ins nos. 1-8 of the corresponding process space 404 
implementation, and the number of stages implemented by and their processing inter-dependencies, 'llie stage configu- 
any single machine, will depend on the application and ration module passes the plug-in configuration information 
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to an execution management framework 425. The execution layout of the plug-ins within each stage, and then selects and 

management framework 425 uses this information to deter- loads individual plug-in parameters, all as will described 

mine which of the plug-ins nos. 1-8 can be processed in next. 

parallel (and during the same clock cycles per clock 420) a first or top level configuration entails configuring the 
and which of the plug- ins nos. 1-8 need to be processed in 5 layout of the pipeline stages. This configuration includes the 
sequence after other plug-ins because they depend on a final following configurable parameters: stages on each machine, 
or intermediary resuh from the other plug-ins. As illustrated, and arrangement and dependencies between stages. The 
those of the plug-ins nos. 1-8 that can be processed in pipeline preferably can run multiple configurations, and, can 
parallel are shown in a vertical stack in the drawing (as in the dynamically switch back and forth between versions. Thus, 
case, e.g., of plug-ins 1, 2 and 3; or plug-ins 6 and 7; or lO for example, where a prior VAS is being replaced with a new 
plug-ins 8 and 9). Moreover, those of the plug-ins nos. 1-8 VAS version, the pipeline can be configured to process 
that are dependent on, and therefore need to be processed session data, e.g., in alternation, from the old VAS and the 
after, other plug-ins are shown to the right of the other new VAS during a transition period in which not all cus- 
plug-ins on which they depend (as in the case, e.g., of tomers have been switched to the new plan. The time stamp 
plug-in 5 dependent on plug-in 4 and thus shown in the ]5 of the session determines which configuration is selected- 
drawing, to the right of plug-in 4). g g,^ prior to a certain date, a first configuration is used, and 

Accordingly, in summary, the illustrated embodiment of after that date, the latter configuration is used, 
the pipeline 130 provides a flexible, distributed system for The next level of configuration is the layout of the 
performing calculations defined and performed by plug-ins plug-ins within each stage. This configuration includes the 
executed in a prescribed order, per data consumer 20 fo^ovving configurable parameters: dependencies between 
requirements, on property name/value pairs of session plug-ins; and properties read, created, and/or modified by 
objects to obtain a set of processed session data for data each stage. This plug-in layout configuration establishes 
consumers. Plug-ins are modular, computer-executable how plug-ins are going to be arranged in the pipeline, and 
computer programs that specify a specific computational the dependencies between the plug-ins. 
function or operation with respect to session objects, llie 25 .^^^ ^^^^^ ^^^^^ configuration in this embodiment is each 
evel of granularity of the computational fiinctions should be -^^^^^^^ of plug-in, which is configurable as to all aspects of 
low enough to make it likely that the plug-ins can be reused .^^ configuration includes the following con- 
fer processing usage data for other VAS The modular nature ^ ^^j^ig parameters: plug-in identifier; and configurable 
of plug-ins permits them to be readily inserted mto the ^^^^eters specific to the plug-in. The behavior of each 
pipeline at any stage executed m any order and added, 30 j changes depending on the parameters with which it 
removed or replaced for modifying the calculation to pro- ^ configured. Preferably, each plug-in has a custom user 
duce a different set of processed session data. The pipehne -^^^^^^^ ^^^^-^ operator-specified values for the 
can process any number of plug-ins in any desired order. parameters that control the behavior of the plug-in. 

Tlie configuration manager 150 (FIG. lA) manages the configuration manager 150 preferably stores the 

configuration of the metered data processing system 104 configuration files in persistent memory, and, pursuant to 

(RG. lA) m scheduhng execution of the plug-ins. The ^p^^^^or instructions, can cause the execution management 

configuration manager 150 provides configuration files to frameworks 225 to load any of the previously stored con- 

the pipeline controller 210 (HG. 2) for controUmg pipeline figuration files for use in processing a session, 
operation m plug-m execution. Ine configuration files 

includes stage configuration files 418 (FIG. 4) for defining E) Plug-ins and Sessions 

plug-ins and their inter-dependencies. Each machine 302, . . . . , . r . 

^i\A /r7ir- i\ f *u - v r Plug-ins Operate on sessions, which are made up of a set 

304, 30o (FIG. 3) of the pipehne can form one or more - . , t - 

1- . -tM in/zn/^ i\ 1- u • r . of property name/value paus. Each mdividual plug-in per- 

pipelinc stages 202, 204, 206 (FIG. 2). Each pipeline stage c I ^ c.t, * *• *i. ^ 

in /I iftr /r-ir- -»\ • i * r K)rm a sub-part of the computation on the property values 

202, 204, 206 (FIG. 2) processes a single session, forms a - .. .. • ,• • . ^r.^ • l 
• 1 ^ ^ K ^ 1-45 performed by the pipeline in its entirety. The sessions have 

single process space, and can process one or more plug-ins. . v .i_ . . . • v 

^ ^ ° service-specific properties that were sent to the pipeline 

D) Configuration Parameters ^^"""^ "^^^ devices, as well as properties generated by the 

pipeline during processing (such as a service name of the 

'Ilie metered data processing system 100 (FIG. 1) is session). Plug-ins that operate on service-specific properties 

configurable for processing sessions pertaining to particular 50 are called "service plug-ins", and those that operate on 

VASs, and thereby obtaining usage data specific to the properties regarding processing system operation, e.g., 

VASs. For processing a session, an operator uses an user logon, are called "system plug-ins". As sessions are passed 

interface (UI) 152 (FIG. lA) of the configuration manager between pipeline stages, plug-ins may create new properties 

150 (FIG. lA) to configure the pipeline 130. The configu- for the use by other plug-ins, for display to the user, or for 

ration manager 150 generates a configuration file for each 55 use by an external system. Properties that are created for use 

stage of the pipeline 518, preferably specifying configura- by other plug-ins and later discarded are termed "ephemeral 

tion data in XML format. The configuration file is sent to properties". After a session has worked its way to the end of 

each stage configuration module 416 (FIG. 4) for configur- the pipeline, it is left with properties containing the results 

ing the respective stage. The configuration file is also sent to of the computational pieces performed by the plug-ins. 

the execution management framework 125 of each stage to 60 These results can be either displayed to the user, stored, or 

configure the plug-ins. The configuration files can be used by an external system. 

distributed, e.g., by a configuration web server included in Session sets are groups of related or unrelated sessions, 

the configuration manager for distribution via HTFP to The pipeline can operate on sessions in batches instead of 

pipeline servers. one by one. Other operations, such as aggregation, require 

ITie configuration files configure the stages and plug-ins 65 plug-ins to create aggregated data from a set of sessions, 

at three-levels. To configure a pipeline, an operator first Session sets provide the abstraction to work with sessions in 

selects and loads a stage layout, then selects and loads a batches. Different session sets have different longevity. 
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Some sets remain in use, e.g., for months at a time, while 
others are used only briefly before being discarded. For this 
reason, session sets must have the ability to remain tempo- 
rarily or persistently in memory. 

Session sets allow certain set operations, such as union 5 
and subset. Sets also allow simple types of aggregation, such 
as summing each value of a certain property from every 
session within the set. A plug-in could iterate through each 
item in a set, summing values or filtering the set appropri- 
ately. 10 

There are several other types of plug- ins that will be 
described separately. A "simple plug-in" operates on a single 
session at a time. In processing the session, a simple plug-in 
may examine existing properties and may create new prop- 
erties. When a simple plug-in completes its operation and 
passes control back to the framework, the session is passed 
on to the next plug-in in the pipeline, A simple plug-in is 
really just a session set plug-in that operates on a set with a 
single session. 

^ 20 

"Set plug-ins" operate on a set of sessions as a batch. The 
set plug- ins can examine any of the properties of any of the 
sessions within the set. They may also create new properties 
for any of the sets. After the set plug-in completes its 
operation, the session set is passed to the next plug-in in the 
pipeline. A basic way to operate on a session set is to iterate 
through each session in the set, working on the sessions one 
by one. If the results of one computation can be applied to 
more than one session, it may be beneficial to sort the set 
first, then work on the set in small groups. For example, a 
plug-in that matches a usemame to an account number 
stored in memory may sort the set by username, look up the 
account number for a user name, then set the account 
number property for each session in the set that had the user 
name. Since the set has been sorted by username, all sessions 
with the same username will appear right next to each other. 
Set plug-ins can remove sessions from the set on which they 
are operating. If a session is removed from a set, no further 
processing is performed on that session. ITiis allows the set 
plug-in to act as a filter, i.e., capable of discarding sessions. 
Sessions in the set may or may not have any relationship to 
each other. The purpose of a set plug-in is not to aggregate 
the data from the set. Aplug-in can caU another plug-in, e.g., 
an aggregation plug-in, described below, to perform a com- 
putation for which it is designed. 

The pipeline is not simply a long scries of plug-ins that 
execute one by one in a predetermined order in sequence or 
in parallel. The plug-ins can make decisions on where the 
session should move next. A "fork plug-in" allows a session 
to begin moving down a new piece of the pipeline. One fork 59 
plug-in splits the pipeline based on service ID. When 
sessions first come in the pipeline, they go through default 
processing and then to service plug-ins that collectively 
"know" how to rate each type of service (i.e., they perform 
the rating calculations for the service). At this decision point, 55 
a fork plug-in looks at the service ID of the session and 
routes the session to the correct service -specific sequence of 
plug-ins. After the service plug-ins have completed their 
work, the sessions are forked back into post-processing 
before the pipeline completes. Complicated rating systems 
will require this type of decision making within the pipeline. 
Fork plug-ins are allowed to fork the pipeline based on any 
set of criteria. 

"Aggregation plug-ins" combine data from a set of ses- 
sions and store that data in a session. After the data is 65 
aggregated once, the pipeline can use the stored data instead 
of having to recalculate the aggregate. An example of 
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aggregating sessions is rating a fax broadcast service that 
sends the same fax to a number of recipients. If the cost of 
the fax broadcast parent session were to be set to the sum of 
the costs of its individual faxes, the combination of a set 
creation plug-in and an aggregation plug-in could be used. 
First, the set plug-in would add each individual fax session 
to a set. Then, when the parent broadcast session came 
through the pipeline, an aggregation plug-in would calculate 
the sum of the set of fax sessions and store that sum in the 
parent fax broadcast session. The parent session could then 
be further rated without having to examine the individual fax 
sessions again. 

Aggregation plug- ins can also be used to aggregate unre- 
lated sessions. If a company wants to see the total number 
of faxes it sent over a month to a certain fax machine, an 
operator could set up a set creation plug-in to add each fax 
session to that number (whether they were part of a broad- 
cast or not) to a set. At the end of the month, a session 
generator could create a session to hold the total number of 
calls to that fax machine. An aggregation plug-in would then 
count the total number of faxes in the set and store that 
number in the newly created session. Aggregation plug-ins 
can preferably set any number of properties in the aggregate 
session, although they preferably may not modify any ses- 
sion in the set. Session sets have operations specifically 
designed to perform this type of aggregation. If possible, 
these operations should be used rather than iterating through 
each session within the set. llie session set is preferably 
optimized to perform this type of task. After an aggregation 
plug-in completes its task, the aggregate session moves on 
through the rest of the pipeline. The session set that was 
operated on remains unchanged. 

F) Stage and Plug-in Configuration and Operation 

FIG. 5 shows a portion 500 of the metered data processing 
system 104 responsible for directing stage and plug-in 
configuration and operation, while taking into account com- 
putational dependencies. As illustrated, a configuration man- 
ager 502 has a user interface 504 for receiving operator- 
specified configuration parameters regarding pipeline stages 
and plug-ins. The configuration manager 502 also includes 
a table or directory 506 for holding dependency data. The 
configuration manager 502 generates configuration files for 
the sessions by enabling a user to select, from a configura- 
tion storage memory 508, configuration data using the user 
interface 504. ITie configuration storage memory 508 can 
include stage configuration parameter storage 509 A, plug-in 
layout parameter configuration storage 509B, and plug-in 
operation parameter storage 509C. Examples of the indi- 
vidual parameters are given above. The plug-in operation 
parameters include selections of the types of the plug-ins as 
just described above, and their specific functions. The func- 
tions can include, for example, performing a mathematical 
operation like adding, subtracting, dividing, multiplying, or 
averaging, to name a few. The functions can also relate to 
processing flow, as performed, for example, by fork plug- 
ins, or session manipulation, as performed, for example, by 
session generator plug-ins. 

This process of configuring the stages and plug-ins can be 
menu driven, with the user selecting from predetermined 
and preloaded configuration parameters. The plug-ins pref- 
erable are pre-existing, reusable computational building 
blocks that the user selects and orders in a desired combi- 
nation and sequence to yield a desired computation, such as 
a calculation formula. Ilie user can devise the formula, or 
can select from preloaded formulas provided by the con- 
figuration storage 508. The configuration manager 502 then 
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Stores the selections, and generates a configuration file dependent on other plug-ins. Generally speaking, given two 

reflecting the selections and pipeline operational character- plug-ins M and N, if plug-in M computes the value x (as a 

istics to effectuate the desired computation, which is also final or intermediary result) and plug-in N requires the value 

stored, preferably persistently, in the configuration storage x to perform its computation, then plug-in N depends on 
5()g 5 plug-in M. Plug-ins can be dependent on zero, one, two, or 

. • c efi'y more, other plug-ins. In the above notation, because of the 

For processing a session, the configuration manager 502 f u. ikt^u. -f* 

• Ji f ^ • noted dependency between M and N, the stage infrastructure 

provides a configuraiioD file to each stage configurauoo ^j,, { ^ ^^ executed before it starts 

module 512, 514. 516 for configuring each respective one of execution of plug-in N. Plug-ins v^ith zero dependencies can 
the stages of the pipeline. The stage configuration modules executed immediately or at any other time, without regard 

512, 514, 516 pass plug-m configuration data to the execu- lo execution of other plug-ins. 

tion management frameworks 522, 524, 526 responsible for f.,^ /-ah** i j j u ztaa 

^ r , ■ . • . FIG. oA illustrates an exemplary dependency graph 600 

du-ecting operation of plug-ins within the respective stages. r • i j r *■ e ^ - - 

. ^ \. . c 1 ^'yK s'^A ff-^? • for specifying a particular order of execution or plug-ins in 

Each execution management framework 522, 524, 526 is -n * *• i* *• a l l *i. i 

„ . c.l . J an illustrative application. As shown by the arrows, plug-m 

preferably associated with a different one oi the stages, and , f nA j i i - au 

icA depends on plug- in B. Accordingly, plug-in A has one 
IS implemented as a computer-executable program that runs -'^ , ^ ^ * j i. «a r» !L *i. l j 

^ , J r u ■ 1- dependency, as represented by A:l . On the other hand, 

on an associated machine of the pipehne. The execution i j ^ • i i i^jrx 

^ c 1 Mir *u *u J plug- in B has two dependencies, namely, plug-ins C and D, 

management frameworks 522, 524, 526 access the thread ^ * . j u «t) o» kt -^u i • i t^u 

, J u J L J 1 as represented by B:2 . Neither piug-m C nor plug-in D has 

pool 528 and serve as thread schedulers to assure proper , , . „^ ^, .f^^ 

^ ^. r *i- 1 • • *i. * J A • any dependency, hence C:0 and U:0 . 

execution of the plug-ms in the correct order. As a session U .i ^ . 

is to be processed within the stage, the execution manage- 20 For execution, the dependency between plug-ins is deter- 
ment framework 522, 524, 526 receives control of the mmed either manually or by the configuration manager, and 
session objects, calls plug-ins for performing sub-parts of recorded in the stage configuration file for the particular 
computations on the session objects, and then receives stage The dependencies noted in the graph can be sorted and 
control again of the session objects after each plug-in ''fd '".'be stage configuration file as described below, 
completes its operations. 25 Alternatively, the graph 600 of the plug-ins can be 

, represented, e.g., by a suitable data structure, array or table 
Tie execution management frameworks 522, 524, 526 configuration file for the particular stage in 

collectively ainstilute an infrastructure that allows any type configuration storage 508 (FIG. 5). 
or number of plug-ins to be arranged and operated in any ^ „ *• u u • c *• • * j -.i. 

, ,\ ^ £ £1 • * J '^u u The configuration file holds information associated with 

order pursuant to a configuration file associated with each u j • *u u j j * * *u i 

• nn- r * .11 1 .lj-.l.j30 each nodc m thc graph 600 as uccded to cxccute the plug-in, 

session. The infrastructure allows plug-ins to be distributed • , - r *• r • *u u c ^ 

, . , J.I f . including information specifying the number of other plug- 

across multiple machines and takes care of the communi- u- u u i • j j -ru * *u * 

, u- o 1 • ins on which each plug-in depends. The stage uses that 

cation across processes and across machines. Some plug-ms . ^ . -i_ i • • .l . i a. 

. , . . . u • M t_ 1 * information m executing the plug-ins in the correct order. At 

have dependencies on certain properties being available at . . • u* u -ui * * *u 

.u * • • * 1 any given time, it might be possible to execute more than 

the time they operate on a session. They, in turn, can supply ^° i • j . j j u *i. *u 

, • *, J Tn. • r 35 one plug-in: if two plug-ms do not depend on each other, the 

properties on which other plug-ins may depend. The infra- , i . K j l 

* 11 • J *' 1 i_i . two plug-ins can be executed in any order, or can be 

structure ensures that all required properties are available at * j ■ i* i /• 11 i j • *i. 

^. , . ^0 . -.J . executed simultaneously (i.e., in parallel during the same 

the time the piug-in runs. Sometunes it does not matter , , ... w 1 *u ^ ^ r c ■ . -c 

... r r 1 • • 11 1 - . • clock cycle) by multiple threads. Therefore, for instance, if 

which one of a group of plug-ins is called at a certain time , : s/, 1 , ^ 'u •* * 

, f *u u 1 1 • r*u a plug-in will take a long time to execute because it must 

because none of them have cross-dependencies on any of the .. .. 1. r j . u u .u 1 • 

. J *u *u 1 • t.' 40 wait on the results of a database query by another plug-in, 

others in the group, and then the plug-ins or the group can ... . ^ . . . 1 ■ • 

, J to*- the pipeline mfrastructure can execute other plug-ms in the 

be run in any order. ^ \. ^. a - .u . u a 

mean time. At any time, any plug-in that has zero depen- 

The pipeline operator can combine plug-ins into large dencies can be executed, 
chunks of fiinctionaHty, called stages Each stage is made up ^^^^^ ^ dependency tracking mechanism 650. 

ofseveral pipeline plug-ms. Tlie pipeline infrastructure caUs ^^^^ ^^^^^^.^^ management framework 652 can be pre- 

each plug-m in a stage in the correct order, managing the ^^^^^^ ^.^^ dependency data 654 from a configuration file 

dependency and load balancmg between the plug-ins. Com- ^^^j^^ ^ configuration manager 602 (FIG. 6A), 

munication between stages is based on a queuing architec- ^^^^^ .^^^ j ^^^^^ dependencies for process- 

ture. Each stage manages a queue of messages, e.g., session ^ ^ ^ .^^^^^^ configuration file including a different set of 

objects. The pipehne infrastructure pulls the session objects dependency data is provided for each stage. The execution 

off the queues when appropriate, and then calls the plug-ms ^.^^gement framework 652 directs execution of each plug- 
m the right dependency order to process the session objects. ^^^^ ^^j^^ ^j^l ^^^^^ ^^^^^ plug-in(s). 

After all the plug-ms have been processed m the stage, the ^^^^ j ^^3, 664, or 666 includes a dependency 

infrastructure sends the session objecLs to the queues of ^^^^^^^^ g^,,^,^ ^^^^ alternatively, is associated with a 

additional stages Any fork plug-ins redirect sessions to counter stored in memory). Prior to execution, the execution 

stages different ^ from the ordmary sequence of stages m management framework 652 causes the counter for each 

which the plug-ins would be processed. pj^^.;^ ,^ ^i,^ ^ j^jj^^j^ .^^ ^^^^^ 

G) Plug-in Dependency Graphs and Execution of plug-ins on which it depends. As a plug-in 662, 664, or 

Q^^^^ ^ 666 completes execution, it notifies the execution manage - 

60 menl framework 652. A count conditioning mechanism, e.g.. 

As noted above, plug-ins can be implemented as modular the illustrated decrementer 672 in the framework 652, causes 

pieces of code that are executed during run-time for per- the counter 670A-C of any plug-ins dependent on the then 

forming a defined task, such as a sub-computation on session executed plug-in to be decremented by a single count. This 

data. Usually, the plug-ins need to be executed in a certain, continues iteratively upon each execution until a predeter- 
specified order to effectuate the desired, overall computation 65 mined threshold is reached, e.g., a count of zero, for a 

performed by the stage that contains them. A complexity is particular plug-in. (Alternatively, an incrementer could be 

introduced in specifying that order because plug-ins can be used, and incremented to a predetermined threshold.) When 
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the threshold is reached for the counter 670A-C of a executed,forexaraple, in parallel. Since plug- in G depended 

particular plug-in 662, 664, 666, that plug-in can be on both plug-ins J and I, its dependency count is decre- 

executed because its dependencies have been resolved. mented to a value of zero. Are-sort yields H:0, G:0, F:l, E:l, 

Returning to the example of FIG. 6A, plug-ins C and D D:l, B: 1. A:l, C:2. Then, plug-ins H and G can be executed, 
can be executed immediately because they do not depend on 5 for example, in parallel. This will cause the counters for each 

other plug-ins, as indicated by the zero in the designations of plug-ins E, F, and D to be decremented by a single count. 

C:0 and D:0. Afterwards, as is the case each time a plug-in Another re-sort yields F:0, E:0, D:0, B:l, A:l, C:2. Then, 

is executed, the dependency counts of counters 670A, ...for plug-ins F, E, and D can be executed, for example, in 

all plug-ins that depend on the executed plug-ins are dec- parallel. This will cause the counter for plug-in C to become 
remented by decrementer 672. Accordingly, as shown in 30 zero. Yet another re-sort yields C:0, B:l, A: 1. Then, plug-in 

FIG. 6C, when plug-in C is executed, the counter for plug-in C can be executed. This will cause the counter for plug-ins 

B (which depends on plug-in C) will be decremented from A and B to be decremented to zero. A re-resort this time 

a value of 2 to a value of 1. Plug- in B now has only one yields B:0, A:0. Finally, both plug-ins B and A can be 

dependency, plug-in D. As shown in FIG. 6D, when plug-in executed, for example, in parallel. 

D is executed, the counter for plug-in B will again be 15 Accordingly, a method of processing plug-ins can be 

decremented, this time from a value of 1 to a value of zero. efficiently implemented in accordance with this aspect of the 

Now, plug-in B has no dependencies and can be executed invention to reflect dependencies between plug-ins while 

immediately. As shown in FIG. 6E, when plug-in B is taking advantage of multi-threading operation within the 

executed, the counter for plug-in A is decremented from a stage, 
value of 1 to a value of zero. As such plug-in A can be 20 

executed immediately. Of course, the plug-ins C and D in Conventional Computer System 

this example could alternatively be executed in the opposite 7 illustrates a conventional system architecture for 

order or in parallel. exemplary computer system 700, with which servers 114, 

To implement this algorithm cfiBciently, the configuration 1I6, the presentation server 140, configuration manager 150, 

manager or execution management framework (depending 602, and individual machines 302, 304, 306 can be imple- 

on the embodiment) can sort plug-ins by their starting mented. The exemplary computer system of FIG. 7 is 

dependency count so as to obtain a plug-in execution list. discussed only for descriptive purposes, however, and 

Accordingly, the list contains specifications of all plug-ins should not be considered a limitation of the invention, 

with zero dependency, followed by all plug-ins with a single Although the description below may refer to terms com- 

dependency, followed by all plug-ins with two monly used in describing particular computer systems, the 

dependencies, and so on. Within each dependency level, for described concepts apply equally to other computer systems, 

example, all plug-ins with a single dependency, the plug-ins including systems having architectures that are dissimilar to 

can be listed (and executed) in any order. The sort order of that shown in FIG, 7. 

the graph configuration shown in FIG. 6A can be for ^he computer system 700 includes a central processing 

example, C:0,D:0,A:1,B:2. All plug-ms that are ready to (^PU) 705, which may include a conventional 

be executed appear at the begmning of the Ust, i.e., they have microprocessor, random access memory (RAM) 710 for 

zero dependency. Each time plug-ms are executed, the temporary storage of information, and read only memory 

dependency counts are updated and the plug-ms are (rq^) 715 for permanent storage of information. A 

re-sorted to reflect their dependency level. This sorting, ^ controller 720 is provided for controlling system 

execution and resortmg process can contmue until all plug- j^q ^ ^us controller 725 is provided for controlUng 

ms have been processed. A number of threads can work on ^us 730, and an interrupt controller 735 is used for receiving 

execulmg plug-ms at the same time. Because aU plug-ms processing various interrupt signals from the other 

with zero dependencies appear at the beginmng of the list, system components. 

threads can simply pull the first item off the list to execute , , , , 

r r Mass storage may be provided by diskette 742, CD-ROM 

,. , , ,. , , . 747, or hard disk 752. Data and software may be exchanged 

Accordingly, the sticcessive sort lists for plug-m execu- ^-^^ ^j.^^^ 7^ removable media, such as 

tion for the graph 600 may be as follows during the ^-^^^^^^ CD-ROM 747. Diskette 742 is insertable 

successive steps of execution: -^^^ ^-^^^^^^ ^^.^^ ^4^^ ^^.^^ connected to bus 730 by 

Step 1: C:0, D:0, A:l, B;2, with plug-in C available for controller 740. Similarly, CD-ROM 747 is insertable into 

execution, CD-ROM drive 746, which is connected to bus 730 by 

Step 2: D:0, A:l, B:l, with plug-in D next for execution. controller 745. Finally, the hard disk 752 is part of a fixed 

Step 3: B:0, A:l, with plug-in B next for execution. disk drive 751, which is connected to bus 730 by controller 

Step 4: A:0, with plug-in A next for execution. 750. 
Then, when A is executed, execution of plug-ins in the 55 User input to the computer system 700 may be provided 

particular stage is completed. by a number of devices. For example, a keyboard 756 and 

Of course, in practice, more complicated dependency a mouse 757 may be connected to bus 730 by keyboard and 

graphs can be encountered. FIG. 6F shows an exemplary mouse controller 755. An audio transducer 796, which may 

graph 690 of such a more complex structure. Node D can be act as both a microphone and a speaker, is connected to bus 
located as shown in the graph 650 at the same level as node 60 730 by audio controller 797. It should be obvious to those 

C, or can be located alternatively at the same level as E and reasonably skilled in the art that other input devices, such as 

F, or at the same level as A and B. The graph 690 yields an a pen and/or tablet and a microphone for voice input, may 

order of execution by following the same rules as discussed be connected to client computer 700 through bus 730 and an 

above in conjunction with FIG. 6A-E. Successive sort appropriate controller, DMA controller 760 is provided for 
orders for the nodes of the dependency graph 690 may be, 65 performing direct memory access to system RAM 710. A 

for example, as follows: Initial sort of J:0, 1:0, H:0, F:l, E:l, visual display is generated by a video controller 765, which 

D:l, B:l, A:l, G:2, C:2. Then, plug-ins J and 1 can be controls video display 770, 
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Cbmputer system 700 also includes a network adapter 790 present interfaces that represent their abstractions cleanly 

that allows the client computer 700 to be interconnected to with no extraneous information. Polymorphism takes encap- 

a network 795 via a bus 791. The network 795, which may sulation a step further. The idea is "many shapes, one 

be a local area network (LAN), a wide area network (WAN), interface". A software component can make a request of 

or the Internet, may utUize general-purpose communication 5 another component without knowing exactly what that com- 

lines that interconnect multiple network devices. ponent is. The component that receives the request interprets 

Computer system 700 generally is controlled and coordi- it and figures out, according to its variables and data, how to 

nated by operating system software. Among other computer execute the request. The third principle is inheritance, which 

system control functions, the operating system controls allows developers to reuse pre-existing design and code, 

allocation of system resources and performs tasks such as This capability allows developers to avoid creating software 

process scheduling, memory management, networking and from scratch. Rather, through inheritance, developers derive 

I/O services. subclasses that inherit behaviors, which the developer then 

A software implementation of components of the above- customizes to meet their particular needs, 

described embodiment may comprise computer instructions Although an exemplary embodiment of the invention has 

and routines either fixed on a tangible medium, such as a ^5 been disclosed, it will be apparent to those skilled in the art 

computer-readable media, e.g. the diskette 742, CD-ROM that various changes and modifications can be made which 

747, ROM 715, or fixed disk 752 of FIG. 1, or transmittable will achieve some of the advantages of the invention without 

via a modem or other interface device, such as communi- departing from the spirit and scope of the invention. It will 

cations adapter 790 connected to the network 795 over a be obvious to those reasonably skilled in the art that other 

medium 791. Medium 791 can be either a tangible medium, 20 components performing the same functions may be suitably 

including but not limited to optical or hard-wire communi- substituted. Further, the methods of the invention may be 

cations lines, or may be implemented with wireless achieved in either all software implementations, using the 

techniques, including but not limited to microwave, infrared appropriate processor instructions, or in hybrid implemen- 

or other transmission techniques. It may also be the Internet. tations that utilize a combination of hardware logic and 

A series of computer instructions embodies all or part of the 25 software logic to achieve the same results. Further, aspects 

functionality previously described herein with respect to the such as the size of memory, the specific configuration of 

invention. Those skilled in the art will appreciate that such logic and/or instructions utilized to achieve a particular 

computer instructions can be written in a number of pro- function, as well as other modifications to the inventive 

gramming languages for use with many computer architec- concept are intended to be covered by the appended claims, 

tures or operating systems. Further, such instructions may be 30 What is claimed is: 

stored using any memory technology, present or future, 1. A system for processing metered information, the 

including, but not limited to, semiconductor, magnetic, system comprising: 

optical or other memory devices, or transmitted using any A) a mechanism for converting the metered information 

communications technology, present or future, including but into session data; and 

not limited to optical, infrared, microwave, or other trans- 35 3) a processing unit for performing calculations on the 

mission technologies. It is contemplated that such a com- session data to generate processed session data, the 

puter program product may be distributed as a removable processing unit comprising an execution management 

media with accompanying printed or electronic framework, and a plurality of processing modules for 

documentation, e.g., shrink wrapped software, pre-loaded processing the session data as directed by the frame - 

with a computer system, e.g., on system ROM or fixed disk, 40 work to perform the calculations, 

or distributed from a server or electronic bulletin board over 2. The system in accordance with claim 1, further com- 

a network, e.g., the Internet or World Wide Web, prising a configuration manager for generating a configura- 

In the illustrative embodiment described above, the tion file for specifying at least one operational parameter for 

computer-executable programs (e.g., the plug-ins and the the processing modules, 

framework) that are part of the metering and processing 45 3. The system in accordance with claim 2, wherein the 
system 100 and the data processed thereby can be imple- configuration file specifies at least one operational parameter 
mented using object-oriented programming techniques. As including an order of operation of the processing modules, 
will be understood by those skilled in the art, Object 4. The system in accordance with claim 2, wherein the 
Oriented Programming (OOP) techniques involve the configuration file specifies at least one operational parameter 
definition, creation, use and destruction of "objects". These 50 including a computational operation for each of the process- 
objects are software entities comprising data elements, or ing modules. 

attributes, and methods, or functions, which manipulate the 5. llie system in accordance with claim 2, wherein the 

data elements The attributes and related methods are treated configuration manager includes a user interface for receiving 

by the software as an entity and can be created, used and operator-specified configuration parameters, including an 

deleted as if they were a single item. Together, the attributes 55 order of operation for the processing modules in accordance 

and methods enable objects to model virtually any real- with data consumer requirements. 

world entity in terms of its characteristics, which can be 6. The system in accordance with claim 2, wherein the 
represented by the data elements, and its behavior, which configuration files specify a configuration for the processing 
can be represented by its data manipulation functions. In this unit, the configuration including an identification of pro- 
way, objects can model concrete things like people and 60 cessing modules and an order for execution of the process- 
computers, and they can also model abstract concepts like ing modules. 

numbers or geometrical designs. 7. The system in accordance with claim 6, wherein the 

The benefits of object technology arise out of three basic session data includes a time stamp, and the configuration 

principles, namely, encapsulation, polymorphism and inher- manager provides a configuration to the processing unit 

itance. Objects hide, or encapsulate, the internal structure of 65 responsive to the time stamp. 

their data and the algorithms by which their functions work, 8. llie system in accordance with claim 7, wherein the 

Instead of exposing these implementation details, objects configuration manager provides a first configuration to the 
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processing unit responsive to the time stamp indicating a 19. The system in accordance with claim 18, wherein the 

time prior to a specified time, and provides a second operational order determining mechanism includes a dcpen- 

configuration to the processing unit responsive to the time dency counter associated with each processing order for 

stamp indicating a time after the specified time. determining a operational sequence position for operation of 

9. The system in accordance with claim 1, wherein the s the associated processing module. 

processing unit includes a pipeline for performing calcula- 20. The system in accordance with claim 18, wherein each 

tions on the session data to generate processed session data, processing unit includes a dependency counter, and com- 

the pipeline comprising a plurality of stages, each of the ^^^^^^ operation when the counter reaches a predetermined 

stages by mcludmg an execution management framework count 

and a plurality of processing modules for processing the no t» * „ • j i • *u 

. ^ , , r, 21. The system in accordance with claim 20, further 

session data as directed by an associated one of the execu- .-ijj- 

- . ^ r *u 1 1 comprising means tor decrementmg the counter included in 

tion management frameworks to perform the calculations. ^ . . . 

10. The .system in accordance with claim 9, further one of the processmg units m response to operation another 
comprising a configuration manager for generating a con- or the processing units. 

figuration file for specifying at least one operation parameter is ^2. The system m accordance with claim 1, wherein the 

for the processing modules, wherein the configuration files Processing modules include a set processing module for 

includes stage configuration files for defining computational operating on a set of the session data from a number of 

dependencies between the stages. transactions as a batch. 

11. The system in accordance with claim 9, further 23, The system m accordance with claim 1, wherem the 
comprising queues interposed between the stages, and 20 processing modules include a fork processing module for 
wherein the stages execute the processing modules non- changing the order of processmg of the session data, 
synchronously ® system m accordance with claim 1, wherein the 

12. The system in accordance with claim 1, further processing modules include an aggregation processing mod- 
comprising a presentation apparatus for providing processed ^\ aggregating session data. 

session data to data consumer. 25 ^^'^ "^^^^""^ processing metered information pertam- 

13. l^e system in accordance with claim 1, in combina- ^ communication service, the method comprising: 
tion with a metering apparatus for collecting the metered A) converting the metered information into session data; 
user information. and 

14. The system in accordance with claim 1, wherein the B) performing calculations on the session data to generate 
session data includes property name/value pairs, and the 30 processed session data using a processing unit, the 
processing modules perform operations including math- performing step comprising using a framework for 
ematical operations, on the property name/value pairs to managing processing, and using a plurality of process- 
obtain a set of processed session data. ing modules for processing the session data as directed 

15. The system in accordance with claim 1, wherein the by the framework to perform the calculations, 
processing modules comprise modular, computer- 35 2 6. The method in accordance with claim 25, further 
executable computer programs that specify a specific com- comprising a configuration manager generating a configu- 
putalional operation with respect to the session data. ration file for specifying a plurality of operational param- 

16. The system in accordance with claim 1, wherein the eters for the processing modules including an order of 
processing modules can operate in an operator-specified operation of the processing modules and a computational 
order within the pipeline. 40 operation for each of the processing modules. 

17. The system in accordance with claim 1, wherein the 27. The method in accordance with claim 26, wherein the 
processing modules can be added, removed, and replaced for configuration manager includes a user interface for receiving 
modifying the calculation performed by the pipeline in operator-specified configuration parameters, including an 
generating processed session data. order of operation for the processing modules in accordance 

18. The system in accordance with claim 1, further 45 with data consumer requirements, 
comprising an operational order determining mechanism for 

tracking an order of operation of the processing modules. ***** 
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